Conversation
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Fine with me, can we already start that separate document? Will Solid 26 manifest in just those two documents or there are going to be more of them? |
|
Should solid26 recommend more items from https://solidproject.org/TR/ to give a fair representation of what is relatively widely implemented and deployed? For instance, taking the data from https://jeff-zucker.github.io/solid-load-profile/ as one source of input, we can infer what's out there in the ecosystem and use that for the implementers guide. I'll let the group be the judge of how to make a cut (e.g., based on count or other criteria) for what's reasonably deployed. I think it is hard to argue against the fact that Solid WebID Profile and Solid Type Indexes are used out there. If solid26 doesn't suggest anything beyond a WebID, it downplays personalisation and the social aspect of Solid, and if anything, looks strange for the state of things in 2026. If there is other concrete data on the ecosystem, let's have a look. |
This comment was marked as resolved.
This comment was marked as resolved.
|
There should be a general recommendation that latest published versions of specifications should be used. That could be expressed along the lines of: at the time of this publication we recommend x but implementers are strongly encouraged to use latest published when available, and if you like to live on the bleeding edge, use the editor's draft. On that last note, solid26 should also take the opportunity to thank implementers (somewhere upfront like in the Introduction) for helping to improve the Solid ecosystem, and any feedback on their implementation experience in meetings, issues etc., would be most appreciated. |
Collect known security/privacy limitations across the pinned specs into a new top-level section with six subsections: - §5.1 WebID Profile Integrity (absorbs the former §3.1.4 on solid:oidcIssuer write-protection; adds WebID 1.0 §Security Considerations on profile-document integrity and the Solid-OIDC guidance that the RDF body is canonical for issuer discovery). - §5.2 Application Authorization (addresses @elf-pavlik #4276686814: WAC/ACP authorize agents not applications, Origin is not client identification, ACP Client-matcher limits). - §5.3 Access Control Leakage (WAC-documented leakage via Location, DELETE/PATCH status codes, lack of mandated audit trails). - §5.4 Personal Data in Access Control and Preferences (WAC PII transitive to acl:Control holders; Preferences Documents hold private data with protection delegated to WAC/ACP). - §5.5 Client Identity and Trust (Solid-OIDC §Out of Scope, §Client Secrets in browser SPAs). - §5.6 Profile and Storage Discoverability (Solid Protocol §Privacy Considerations; WebID 1.0 absence of privacy section). The new section explicitly notes it was drafted with generative-AI assistance to kickstart coverage and that community review is expected. Update §3.1 intro and TOC accordingly: §3.1.4 gone, new §5 + subsections added.
Done in |
Previous draft had six subsections and fifteen bullets that were overkill for the guide's scale. Collapse to a single flat list of the four points implementers most need to know: - WebID integrity (solid:oidcIssuer server protection) - Authorization authorizes agents, not applications - Consent transitivity in access control - Client identity / no-secrets-in-SPA Drop the WAC leakage subsection, Preferences delegation bullet, profile-discoverability subsection, and the header-vs-body spoofing footnote — these are real but niche, and their spec citations give implementers a pointer if they need them. TOC simplified accordingly: §5 has no subsection entries.
There was a problem hiding this comment.
Omit : "Do not traverse further: discovery links in the documents fetched by this step, in extended profiles discovered from the Preferences Document, and in Type Index documents are not followed."
Add : Clients must descend two levels from the WebID document looking for extended profile links and may descend as far as they want. An author who places an extended document link in an extended document linked from the WebID profile should expect that second document to be read by clients. They can not count on links further away being discovered.
Note : I am not adamant about allowing extended document links in the type indexes and preferences file although I can think of many use cases for those. What I am adamant about is the ability to go at least two levels from the WebID document for extended documents other than the Preferences and Type Indexes.
| <ol> | ||
| <li><code>GET</code> the WebID Document. If it cannot be retrieved, surface a clear error.</li> | ||
| <li><code>GET</code> each linked document: Extended Profile Documents via <a href="#dfn-discovery-links">discovery links</a>, the Preferences Document via <code>pim:preferencesFile</code>, and Type Index documents via <code>solid:publicTypeIndex</code>/<code>solid:privateTypeIndex</code>. On <code>401</code>/<code>403</code> with a logged-in user, retry authenticated; Preferences and the private Type Index normally require authentication [<cite><a class="bibref" href="#ref-webid-profile">Solid WebID Profile</a></cite> § <a href="https://solid.github.io/webid-profile/#discovery">Discovery</a>, § <a href="https://solid.github.io/webid-profile/#private-preferences">Private Preferences</a>]. If the WebID Document does not link a Preferences Document or Type Index documents, those fetches are skipped; their absence is not an error.</li> | ||
| <li>For each Extended Profile Document linked directly from the WebID Document, fetch the Extended Profile Documents it links via its <a href="#dfn-discovery-links">discovery links</a>. Do not traverse further: discovery links in the documents fetched by this step, in extended profiles discovered from the Preferences Document, and in Type Index documents are not followed. Use cycle detection so no document is fetched twice.</li> |
There was a problem hiding this comment.
Line 574 directly contradicts line 565 and line 581 and introduces a much too restrictive set of bounds. The minimum set of bounds is, in my opinion, 2 traversals. This mandates nothing about the writability of any document, only that if there are links in an extended doc to other extended docs we should be expected to follow them at least one level, i.e. two levels from the WebID Document.
Here are two examples of what a limit of one link would prevent
<WebID1> rdfs:seeAlso <friendsAndFamily.ttl> .
<friendsAndFamily.ttl> rdfs:seeAlso <familyOnly.ttl> .
When permissioned accordingly, this pattern allows family to see the more general friendsAndFamily data and also the more specific family data, i.e. inheritance. Why would we want to prevent that kind of security structure?
Also prevented by a limit of one
<WebID1> owl:sameAs <WebID2> .
<WebID2> rdfs:seeAlso <myCV.ttl> .
With a limit of one, a discovery of WebID1 will not turn up myCV.ttl.
A limit of one greatly limits the freedom of users to partition and control their data.
This limit is in contradiction to the WebID Profile Draft and the drafts which preceded it and is being introduced at the last minute. Either drop the limit entirely or make it two levels.
|
|
||
| <div class="note"> | ||
| <h4><span>Note</span></h4> | ||
| <p>When the WebID Document is not hosted in Solid storage, clients cannot add new <a href="#dfn-discovery-links">discovery links</a> to it. The one level of traversal from Extended Profile Documents in Solid storage lets a client attach further Extended Profile Documents (for example, at different access levels) via links it can write.</p> |
There was a problem hiding this comment.
This introduces a completely unnecessary split between types of servers, requiring clients to follow differing expectations. It adds complexity to discovery. It allows the Identity server's decision on storing the WebID to control the ability for discovery on the Resource server and takes capabilities away from WebID owners. Why should we have to tell clients "If you're on server A, do B, but if you're on server C, do D?
There was a problem hiding this comment.
Also, this completely contradicts line 574.
The one level of traversal from Extended Profile Documents in Solid storage lets a client attach further Extended Profile Documents (for example, at different access levels) via links it can write.
No, if clients are only expected to descend one level from the WebID Document this advice is useless since clients will never follow those links.
Apply the three suggestion comments on PR #776: - Line 501: '(e.g. #me)' -> '(e.g., #me)' - Line 530: '(i.e. an unauthenticated...)' -> '(i.e., an unauthenticated...)' - Line 565: '(e.g. pim:storage...)' -> '(e.g., pim:storage...)' Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Per discussion on PR #776: defer to the Security and Privacy Considerations sections of the relevant sub-specifications rather than restate them here. Removes §5 entirely along with its TOC entry and the §3.1 cross-reference. Solid-OIDC third-party-issuer concerns raised by @csarven and the additional point about issuer-trust requirements regardless of issuer scale are being taken upstream to the Solid-OIDC spec.
Add a second bullet to §2.5 Solid WebID Profile flagging that most server implementations do not conform to the Protected Properties requirement, and the security consequence: an agent with write access to the WebID Document can rewrite solid:oidcIssuer and impersonate the WebID owner. Co-located with the existing Solid WebID Profile section.
- §2.1 access-control bullet: name the SAI Authorization Agent as a concrete example of an access-management Client (per @elf-pavlik on PR #776). - §4 data discovery note: hyperlink Solid Application Interoperability to TR/sai. Add an editor's note that a Type Indexes link will be added once PR #786 (which lists Type Indexes as a TR work item) is merged.
11 participants
This is the beginning of the implementors guide discussed in #773 - currently it just fixes the specs and versions to be included.
Additional specs such as #774 (which I acknowledge I still owe a response to) may be added to this guide if developed and CG endorsed in time.
A preview link can be found here.
EDIT since there is a lot of active editing on this PR -- I am marking comments as resolved as I implement changes to ease navigation (cc @csarven @elf-pavlik - I hope this is ok, as far as I understand anyone with read access can still expand and read the content as they desire).